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When using existing ACL2 datatype frameworks, many theorems require type hypotheses. These 
hypotheses slow down the theorem prover, are tedious to write, and are easy to forget. We describe a 
principled approach to types that provides strong type safety and execution efficiency while avoiding 
type hypotheses, and we present a library that automates this approach. Using this approach, types 
help you catch programming errors and then get out of the way of theorem proving. 


1 Introduction 

ACL2 is often described as “untyped,” and this is certainly true to some degree. Terms like (+ 0 
"hello"), which would be not be accepted by the static type checks of languages like Java, are legal 
and well-defined in the logic, and can even be executed so long as guard checking is disabled. Terms like 
(/ 5 0), which would be well-typed but would cause a run-time error in most programming languages, 
are also logically well-defined and can also be execufed when guards are nof checked. 

Of course, mosf ACL2 code is wriffen wifh particular fypes in mind, offen expressed as fhe guards 
of fhe funcfions. When proving properties of such code, if’s easy fo gef fripped up by comer cases 
where some variables of fhe fheorem are of fhe wrong fypes. To avoid fhis, one sfrafegy is fo begin a 
fheorem wifh a lisf of fype hypofheses, one for each variable mentioned. These hypofheses acf as a kind 
of insurance: we may nof know whefher fhey’re necessary or nof, buf including fhem mighf save us from 
having fo debug failed proofs caused by missing fype assumptions. 

On fhe ofher hand, lisfs of fype hypofheses are offen repetitive, fake fime fo wrife, and make fhe 
formulas we’re proving larger and less eleganf. We can hide much of fhis wifh macros, e.g., fhe define 
ufilify has special opfions like : hyp : guard for including fhe guard as a hypofhesis in refum-value 
fheorems. Buf even fhen, fhese hypofheses will cause exfra work for fhe rewrifer since if musf relieve 
fhem before if can apply our fheorem, and may make if harder fo carry ouf lafer proofs since our fheorem 
will nof be applied unless ifs hypofheses can be relieved. 

Accordingly, affer we have proven a fheorem, a good pracfice is fo fry fo “sfrengfhen” if by removing 
any unnecessary hypofheses. There is even a fool, remove-hyps, fhaf fries fo aufomafically idenfify 
unnecessary hypofheses ex posf facfo. While sfrengfhening fheorems is useful, if is limifed. For insfance, 
we (of course) cannof eliminafe fype hypofheses fhaf are acfually necessary for fhe formula fo be a 
fheorem. If can also be fedious, e.g., automation such as define’s :hyp : guard does nof provide a 
convenienf way fo remove parfs of fhe guard. This is nof a purely fheorefical concern; see for insfance 
ACL2 Issue 167, a requesf for such a feafure. 

An alfemafe sfrafegy, which is well-known and cerfainly nof novel, is fo more carefully code our 
funcfions so fhaf fhey always freaf ill-fyped inpufs according fo some particular yir/ng convention. By 
following fhis approach, we can fypically avoid fhe need for fype hypofheses alfogefher. Many examples 
of fhis approach can be found fhroughouf ACL2. To name a few: 
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• Arithmetic functions treat non-numbers as 0; functions expecting a particular type of number 
(integer, natural) treat anything else as 0—e.g., zp, nth, logbitp. 

• Functions expecting a string treat a non-string as ""—e.g., char, (coerce x ’ list). 

• Any atom is treated as nil by car, cdr, endp, etc. 

• The std/osets [5] library functions treat non-sets as nil. 

Following this strategy typically takes a small bit of initial setup, e.g., to agree upon and implement 
a fixing convention. But once this convention is in place, type hypotheses can be eliminated from many 
theorems. For instance, we have unconditional theorems such as a + b = b + a without hypotheses 
about a and b being numbers, and X FX without hypotheses about X being a set. By eliminating type 
hypotheses, these theorems become easier to read and write, and can be more efficiently and reliably 
used to simplifying later proof goals. 

Unfortunately, existing datatype definition frameworks for ACL2 don’t provide any easy way to 
follow the fixing strategy. For example, consider the available macros for introducing product types, like 
def structure [3], defdata [4], and def aggregate. These macros define constructors and accessor 
functions that do not support any particular convention for dealing with ill-typed fields or products. 
Consider a simple student structure introduced by: 

(defaggregate student 
((name stringp) 

(age natp))) 

The constructor and accessors for student structures will have strong guards that are useful for 
revealing programming errors in function definitions. However, in the logic, nothing prevents us from 
invoking the student constructor on ill-typed arguments. For instance, in cases like: 

(make-student :name 6 :age "Calista") 

the constructor fails to produce a valid student-p. The accessors suffer from similar problems, for 
instance the following term is equal to 6, which is not a well-typed student name: 

(student->name (make-student :name 6 :age "Calista")) 

Consequently, reasoning about these structures almost always requires type hypotheses. Since the types 
defined by these frameworks are often found at the lowest levels of ACL2 models, these hypotheses 
percolate upwards, infecting the entire the code base! 

In this paper, we address this problem with the following contributions: 

• We present, in precise terms, a fixtype discipline for working with types in ACL2 (Section 2). 
This discipline allows efficient reasoning via avoiding type hypotheses, strong type checking via 
ACL2’s guard mechanism, and preserves efficient execution via mbe. 

• Manually following the fixtype discipline would be tedious. Accordingly, we present a new library, 
FTY (short for “fixtypes”), which provides automation for following the discipline (Section 3). The 
FTY library contains tools that automate the introduction of new types and assist with creating 
functions that “properly” operate on those types. 

While there is room for improvement (Section 4), the approach and automation that we present is 
practical and scales up to complex modeling efforts. We have successfully used FTY as the type system 
for two large libraries: VL, which processes Verilog and SystemVerilog source code; and SV, a hardware 
modeling and analysis framework. VL, in particular, involves a very complex hierarchy of types. For 
instance, it includes a 30-way mutually recursive datatype that represents System Verilog expressions, 
types, and related syntactic constructs. 
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2 The Fixtype Discipline 

We begin, in this section, by describing in precise terms a fixtype discipline for working with types in 
ACL2. In our experience, following this discipline is an effective way to obtain the benefits of strong 
type checking while keeping types out of the way of theorem proving. 

The basic philosophy behind the fixtype discipline is that all functions that take inputs of a particular 
type should treat any inputs that are not of that type in a consistent way. This can be done using fixing 
functions. 

Definition 1. A fixing function yix for a (unary) type predicate typep is a (unary) function that (1) always 
produces an object of that type, and (2) is the identity on any object of that type. That is, it satisfies: 

(1) Vx: typep{fix{x)) 

(2) Vx : typep{x) =^fix{x) = x 

Given a fixing function, an easy way to ensure that some new definition treats all of its inputs in a 
type-consistent way is to immediately apply the appropriate fixing function to each input before proceed¬ 
ing with the main body of the function. For guard-verified functions, this preliminary fixing can be done 
for free using mbe. Alternatively, if all occurrences of an input variable in the function’s body occur in 
contexts that are already type-consistent, then explicit fixing isn’t necessary. 

When a function follows this approach, the fixing functions become “transparent” to that function. 
For instance, since nth properly fixes its index argument to a natural number, the following holds: 

(defthm nth-of-nfix 

(equal (nth (nfix n) x) 

(nth n x))) 

Given any fixing function, we can define a corresponding equivalence relation. For instance, for 
naturals, we can define nat-equiv as equality up to nfix: 

(defun nat-equiv (x y) 

(equal (nfix x) (nfix y))) 

Functions that properly fix their arguments will satisfy a congruence for this equivalence under equal¬ 
ity: that is, they produce equal results when given equivalent arguments. For instance, for nth: 

(defthm nat-equiv-congruence-for-nth 
(implies (nat-equiv n m) 

(equal (nth n x) 

(nth m x))) 

:rule-classes :congruence) 

We can now define our fixtype discipline. 

Definition 2. A function follows the fixtype discipline if, for each typed input, the type has a corre¬ 
sponding fixing function and equivalence relation, and the function produces equal results given type- 
equivalent inputs. 

A consequence of following the fixtype discipline is that theorems can avoid type hypotheses. 
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Theorem 1. Let typep be a type and let = be the equivalence relation induced by a fixing function for 
typep. Let C{x) be a conjecture satisfying the congruence 

{x = x') (C (;c) C {x ')). 

Then C{x) is a theorem if and only if typep (x) C{x) is a theorem. 

This congruence means that C{x) is a formula where the variable x is consistently treated according 
to the fixing discipline for typep', in this case, it isn’t necessary to include typep{x) as a hypothesis. This 
generalizes easily to additional variables. 

3 The FTY Library 

If we want to follow the fixtype discipline, all of our type predicates need to have corresponding fixing 
funcfions and equivalence relafions. Also, as we infroduce new funclions fhaf operafe on fhese fypes, we 
need fo prove fhaf fhese funcfions satisfy fhe appropriafe congruences, i.e., fhaf fhey freaf fheir inpufs in 
a fype-consisfenf way. 

Alfhough fhese definifions and proofs are sfraighfforward, if would be very fedious fo carry fhem 
ouf manually. If would also be difficulf fo make use of libraries like std/util or defdata since fhe 
funclions fhese frameworks infroduce do nol follow fhe fixfype discipline. This is unforfunafe because 
fhese libraries really make if far more convenienf fo infroduce new types. 

To address Ihis, we have developed a new library, named FTY, which provides several ufilifies fo 
aufomafe fhis boilerplate work and fo facililale fhe infroducfion of new fypes fhaf follow fhe discipline. 
Among fhese ufilifies, we have: 

• deffixtype, which associates a type predicate wifh a fixing function and equivalence relation, 
for defining base types like natp, stringp, and custom user-defined base types. (Section 3.1) 

• def types and associated utilities defprod, deftagsum, def list, def alist, and more, which 
define new derived fixlype-complianl producl types, sum types, lisl types, efc. (Section 3.2) 

• deffixequiv and def f ixequiv-mutual, which prove fhe appropriate type congruences for 
functions fhaf operate on fhese types. (Section 3.3) 

We now briefly describe fhese ufilifies. We focus here on whal fhese ufilifies aufomafe and how fhis 
helps to make if easier fo follow fhe fixfype discipline. More defailed informalion on how fo practically 
make use of fhese ufilifies, fheir available opfions, efc., can be found in fhe FTY documenfafion [8] in 
the ACL2-i-Books Manual. 

3.1 Deffixtype 

The FTY library uses an ACL2 table to record the associations between the name, predicate, fixing 
funcfion, and equivalence relafion for each known fype. This informalion is used by many laler FTY 
ufilifies fo improve automation. For inslance, when we define a new slruclure, fhis fable allows us fo 
look up fhe righf fixing funcfion and equivalence relafion to use for each field jusf by ifs fype, wilhouf 
needing fo be repelifively fold fhe fixing function and equivalence relafion for every field. 

The deffixtype ufilify is used to regisfer new base types, i.e., types fhaf are nol defined in terms of 
olher FTY fypes, wifh fhis fable. Here is an example, which regislers a new fype named nat, recognized 
by natp, wifh fixing funcfion nf ix, and wifh fhe equivalence relation nat-equiv: 
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(deffixtype nat 
:pred natp 
:fix nfix 
:equiv nat-equiv) 

The type name does not need to be a function name; we typically use the name of the predicate 
without the final “p” or “-p.” The predicate and fixing function must always be provided by the user 
and defined ahead of time. Deffixtype can automatically define the equivalence relation based on the 
fixing function, or it can use an existing equivalence relation. 

We usually do not need to invoke deffixtype directly. FTY includes a basetypes book that sets up 
these associations for basic ACL2 types like naturals, integers, characters, Booleans, strings, etc. When 
new derived types are introduced by FTY macros like deftypes (Section 3.2), they are automatically 
registered with the table. On the other hand, deffixtype is occasionally useful for defining low-level 
custom base types, or types that use special encodings, or that for some other reason we prefer not to 
introduce with deftypes. 

Choosing a good fixing function for a type is not always straightforward. As far as the fixtype 
discipline and the FTY library is concerned, any function that satisfies Definition 1 suffices. However, 
the way in which ill-typed objects are mapped into the type affects which functions will have proper 
congruences for the induced equivalence relation. Some choices are dictated by pre-existing ACL2 
conventions; for example, if we wrote our own my-nat-fix function that coerced non-naturals to 5 
instead of 0, then this fixing function wouldn’t be transparent to built-in functions such as zp and nth. 

The fixing function’s guard may optionally require that the input object already be of the type. This 
allows the fixing function to be coded so that it is essentially free to execute, using mbe so that the 
executable body is just the identity. It is also generally useful to inline the fixing function to avoid the 
small overhead of a function call. For example: 

(defun-inline string-fix (x) 

(declare (xargs :guard (stringp x))) 

(mbe :logic (if (stringp x) x "") 

:exec x)) 

3.2 Deftypes and Supporting Utilities 

Whereas deffixtype is useful for registering base types and special, custom types, the deftypes suite 
of tools can be used to easily define common kinds of derived types. The constructors, accessors, and 
other supporting functions introduced for these types follow the fixtype discipline, and the new types are 
automatically registered with deffixtype. There are utilities for introducing many kinds of types: 

• def prod, which defines a product type, 

• def tagsum, which defines a tagged sum of products, 

• def list, which defines a list type which has elements of a given type, 

• def alist, which defines an alist type with keys and values of given types, 

• def option, which defines an option/maybe type, 

• and others. 

Using these macros is not much different than using other data definition libraries. For instance, we 
can introduce a basic student structure as follows: 
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This is very much like introducting a structure with def aggregate: it produces a recognizer, con¬ 
structor, accessors for the fields, b* binders, and readable make/change macros. Unlike def aggregate, 
it also generates a fixing funcfion, student-fix, an equivalence relafion, student-equiv, and regis¬ 
ters fhe new sfudenf fype wifh deff ixtype. The consfrucfor and accessor funcfions for fhe new fype 
also follow fhe fixlype discipline, e.g., we uncondifionally have fheorems such as: 

• (student-p (student name age)) 

• (stringp (student->name x)) 

• (natp (student->age x)) 

A nofable fealure of def types is fhaf if also provides sfrong support for mufually recursive fypes. In 
particular, several calls of utilities such as defprod, def list, efc., may be combined inside a def types 
form fo creafe a mufually-recursive clique of fypes. For example, fo model a simple arifhmefic ferm 
language such as: 


aferm = Num {val :: integer} 

I Sum {args :: Lisf aferm} 

I Minus {arg :: aferm} 

We mighf write fhe following def types form: 

(deftypes arithmetic-terms 
(deftagsum aterm 

(:num ((val integerp))) 

(:sum ((args atermlist))) 

(:minus ((arg aterm)))) 

(deflist atermlist 
:elt-type aterm)) 

As you mighf expecf, fhis form creates fhe basic predicates, fixing funcfions, and equivalence relafions 
for aterms fhaf are needed for fhe fixfype discipline: 

• Predicates aterm-p and atermlist-p, 

• Fixing functions aterm-f ix and atermlist-f ix, and 

• Equivalence relations aterm-equiv and atermlist-equiv. 

If also registers fhe new fypes wifh deff ixtype. The form also defines several funcfions and fools for 
working wifh fhese new fypes, all of which have appropriafe congruences for fhe fixfype discipline: 

• A kind funcfion, aterm-kind, fo determine fhe kind of an aterm, e.g., :num, : sum, or : minus. 

• Consfrucfors for each kind of aterm: aterm-num, aterm-sum, and aterm-minus, and associated 
make/change macros in fhe sfyle of def aggregate/defprod. 

• Accessors for each kind of aterm: aterm-num->val, aterm-sum->args, aterm-minus->arg 
and associated b* binders. 
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• Measure functions, aterm-count and atermlist-count, appropriate for structurally recurring 
over objects of these types. 

For convenience, a macro aterm-case is also introduced. This macro allows us to implement the 
common coding scheme of cases on the kind of an aterm, followed by binding variables to any needed 
fields of the product. Here is a simple example of using aterm structures. 

(defines aterm-eval 

(define aterm-eval ((x aterm-p)) 
measure (aterm-count x) 

:returns (val integerp) 

:verify-guards nil 
(aterm-case x 
:num x.val 

:sum (atermlist-sum x.args) 
minus (- (aterm-eval x.arg)))) 

(define atermlist-sum ((x atermlist-p)) 
measure (atermlist-count x) 

:returns (val integerp) 

(if (atom x) 

0 

(+ (aterm-eval (car x)) 

(atermlist-sum (cdr x))))) 

/// 

(verify-guards aterm-eval)) 

3.3 Deffixequiv and Deffixequiv-mutual 

Together, def f ixtype and def types allow us to largely automate the process of introducing new types 
that support the fixtype discipline. But this is only half the battle. When we define new funcfions 
fhaf make use of fhese types, we are still left with the task of proving that these functions satisfy the 
appropriate congruences for every argument of these types. If our model or program involves many 
function definitions, this can be a lot of tedious work. 

To automate this process, FTY offers two related utilities, deffixequiv and deffixequiv-mutual. 
These utilities are integrated with define and defines and also make use of the table of types from 
def fixtype. This allows them to figure ouf whaf fheorems are needed, offen wifhouf any help af all. In 
particular, fhe types of the arguments are inferred from the extended formats of the each function. The 
corresponding fixing funcfions and equivalence relations can then be looked up from the table, and the 
appropriate congruence rules can be generated. Besides congruence rules, we additionally generate rules 
that normalize constant arguments to their type-fixed forms. 

Consider the aterm-eval example above. To generate the congruence rules for both aterm-eval 
and atermlist-eval, it suffices to invoke: 

(deffixequiv-mutual aterm-eval) 

The deffixequiv-mutual macro determines the types of the arguments by examining the guards spec¬ 
ified in the def ine formats, and it uses the flag induction scheme produced by def ines to automatically 
prove the congruence. 
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For recursive or mutually-recursive functions, proving a congruence directly can be difficult because 
there are two calls of the function in the statement of the theorem, and these two calls may suggest differ¬ 
ent induction schemes that may not be simple to merge. However, the congruences we are concerned with 
follow from the fact that the fixing function is fransparenf fo fhe funcfion, which can usually be proved 
sfraighfforwardly by induction on fhe function’s own recursion scheme. In practice, fhe deff ixequiv 
and def f ixequiv-mutual ufilifies usually fully aufomafe fhe derivation of fhe congruence from fhe 
fransparency fheorem. 

Even if we only need fo wrife a def f ixequiv or def f ixequiv-mutual form affer each definition, 
this can be easy to forget. To further automate following the discipline, you can optionally enable a 
post-define hook that will automatically issue a suitable deff ixequiv command after each definition. 
See the documentation for f ixequiv-hook for details. 

4 Challenges and Future Work 

The FTY library provides a robust implementation of a type system that would feel familiar to users 
of strongly typed functional programming languages such as Haskell or ML. However, there are a few 
pitfalls in their practical use, which we discuss below along with potential solutions. 

4.1 Generic Functions 

The most common problem in working with the fixtype discipline is in the use of generic functions such 
as assoc, append, and many others. These functions are designed to work on objects of nonspecific 
type, and therefore don’t follow fixing conventions for specific types. One can always apply appropriate 
fixing functions to the inputs of these functions, so programming with them in a fixtype discipline isn’t 
hard. However, applying this simple strategy to theorems will often result in ineffective rewrite rules. 

For example, suppose (bind-square-to-root key alist) fixes key to type natp and alist to 
type nat-nat-alist-p, and we want to prove a theorem like the following: 

(equal (assoc k (bind-square-to-root k rest)) 

(or (and (square-p k) 

(cons k (nat-sqrt k))) 

(assoc k rest))) 

Presumably this isn’t true without some type assumptions. One way to fix the theorem is to apply 
fixing functions everywhere that typed variables are used in generic contexts: 

(equal (assoc (nfix k) (bind-square-to-root k rest)) 

(or (and (square-p k) 

(cons (nfix k) (nat-sqrt k))) 

(assoc (nfix k) (nat-nat-alist-fix rest)))) 

But this rewrite rule is not always applicable. The left hand side will match only when we have an 
explicit nfix in our goal, but this nfix is likely to be simplfied away in cases where the key is known to 
be a natural. In these cases, a formulation with a type hypothesis would work: 

(implies (natp k) 

(equal (assoc k (bind-square-to-root k rest)) 

. . .)) 
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Unfortunately, this rule typically won’t allow us to simplify terms such as: 

(assoc (nfix k) (bind-square-to-root k rest)) 
because it fails to unify. In general, both kinds of terms may be encountered and both formulations of 
the rule may be useful. To solve this problem, one might consider automation to generate both forms of 
the theorem, or to generate a theorem that catches both cases as follows: 

(implies (and (syntaxp (or (equal kl k) (equal kl ‘(nfix ,k)))) 

(nat-equiv kl k) 

(natp kl)) 

(equal (assoc kl (bind-square-to-root k rest)) 

. . .)) 

For the moment, unfortunately, reasoning about a mix of generic functions with fixtype-discipline 
functions seems to require the sort of consideration of types that we had hoped to avoid. We generally 
deal with these problems on an ad-hoc basis, either by proving both forms of the theorem or, in more 
problematic cases, by introducing typed alternatives to the generic functions involved. 

4.2 Subtypes 

It is possible to use the FTY library to define two types that have a subtype relation, but the library 
doesn’t have any automation for proving or making use of this relationship. 

In practice, we have found it difficult to get subtype relations to work well. Proving theorems about 
a mixture of functions that operate on sub- and supertypes has the same problems as proving theorems 
with a mixture of generic and fixtype functions, as discussed above. Reasoning about a subtype hierarchy 
also can lead to degraded prover performance, since proving that something is of type A may lead by 
backchaining to attempting to prove it to be of each subtype of A. 

4.3 Parameterized Types 

Haskell and ML support types that take other types as parameters, e.g.. List A signifying a list of objects 
of type A, where A is a type variable. Function signatures may contain types that are not fully specified, 
and these functions may later be used in contexts where the type variables are concretized as particular 
types. 

Selfridge and Smith [17] created a macro library that supports a form of polymorphism by automating 
the creation of instances of the def sum macro. Polymorphic functions are then supported by another set 
of macros that allow one to instantiate a template function definition with different substitutions for type 
variables. A similar macro library could be used to add polymorphism via templates to FTY, but this has 
not yet been done. 

4.4 Dependent Types 

Correct behavior of multiple-input functions often depends on constraints involving more than one of the 
inputs. The fixtypes discipline is focused on unary types, but occasionally it is desirable for a product type 
to contain multiple elements that have constraints linking them. We have experimentally implemented 
support for this in defprod and def tagsum by allowing the user to specify these constraints along with 
an extra fixing sfep fhaf forces fhe fields fo satisfy these constraints; this works in practice for simple 
constraints like “a literal’s value should fit into its width.” We expect that there would be difficulties in 
formulating constraints between subfields of a recursive dafa sfrucfure. 
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4.5 Symbolic and Logical Evaluation 

Execution efficiency of functions using the fixtype discipline is highly dependent on the use of mbe to 
avoid calling fixing functions. Evaluation in the logic (with guard checking turned off) is much more 
expensive with such functions because the : logic part of the mbe then needs to be executed. 

This problem also applies to symbolic evaluation with the GE system [18]. GE is used in hardware 
verification at Centaur and elsewhere; it evaluates ACE2 functions on bit-level symbolic inputs, pro¬ 
ducing bit-level symbolic results, allowing the use of SAT or BDD reasoning to prove ACE2 theorems. 
However, GE ignores guards (except for concrete evaluation) and instead symbolically simulates the 
logical definitions of functions. Therefore, when using GE on fixtype-compliant functions, these fixing 
functions will be unnecessarily (symbolically) executed frequently. 

This extra expense could be problematic in some cases. In future work we expect to address this by 
adding a facility to ETY to generate extra GE rules to help it avoid executing fixing funcfions. Currently, 
we have worked around this problem in some cases by using fixing funcfions that are cheap to symboli¬ 
cally execute. Eor example, if we are dealing with, say, a 32-bit unsigned integer type, then for symbolic 
simulation it is cheaper to use (loghead 32 x) rather than (if (unsigned-byte-p 32 x) x 0) as 
the fixing funcfion. This expense of fixing can also be avoided by creafing custom symbolic counterparts, 
which are used in important core routines in hardware verification frameworks like ESIM and SV. 

4.6 Traversal of Complicated Data Structures 

In languages like ME or Haskell, it is possible to write higher order functions for traversing deeply nested 
data structures. This capability goes a long way toward making it reasonable to inspect and manipulate 
such objects. Since ACE2 is first order, we cannot write these kinds of generic traversals. Instead, we 
have to duplicate the boilerplate code for traversing a structure in each algorithm that operates on it. This 
can become very tedious. 

Eor example, the parsetree format for the VE Verilog/SystemVerilog toolkit contains 168 datatypes, 
132 of which are defined in terms of other types (as a product, list, etc.), reflecting the complexity of 
the SystemVerilog language. We might like to, for instance, collect all identifiers used in a module. 
We might also like simplify all expressions throughout a module. Doing either of these will require 
traversing many of the same structures (modules, declarations, assignments, etc.) to reach the objects of 
interest (identifiers, expressions). 

We have implemented an experimental utility, def visitor, intended to generate the boilerplate code 
necessary for these situations. The user provides code to be run on certain types and to combine results 
from recursive calls, and the utility generates the boilerplate to traverse the data structures. The current 
implementation is a proof of concept and its user interface is likely to change, but it has been used to 
implement several algorithms within the VE library. 


5 Related Work 

5.1 Fixing Conventions 

The use of fixing conventions to avoid hypotheses is well studied and has been used since the earliest 
Boyer Moore provers. In Boyer and Moore’s 1979 A Computational Logic we find a fix function for 
NQTHM’s naturals and hypothesis-free theorems such as the commutativity of plus. Boyer and Moore 
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credit A. P. Morse as the inspiriation for this approach, citing his treatment of set theory, A Theory of 
Sets [161, and recalling^ that: 

“Morse tried every way he could to fix every function that he introduced to eliminate 
hypotheses if possible, without doing any damage. He delighted in such theorems as that and 
and or distributed over one another for all arguments, no matter what objects the arguments 
were, no matter that and was the exact same as set intersection and that or was the same as 
set union.” 

In their 1994 Design Goals for ACL2, Kaufmann and Moore reflect that “NQTHM’s logic gets incredible 
mileage out of the notion that functions—especially arithmetic functions—default ‘unexpected’ inputs to 
reasonable values so that many theorems are stated without hypotheses.” As a result, fixing convenfions 
were used liberally in fheir new fheorem prover, e.g., fhroughouf ifs complefion axioms for primifive 
funclions on numbers, characfers, sfrings, efc. 

Since fhen, many ACL2 libraries such as std/osets [5] and bitops, have made heavy use of fhe 
technique. Perhaps fhe mosf exfreme examples are found in misc/records [14] and related work such 
as fyped records [llj, def exec-enhanded records 1121 . memories [6], and defrstobj, which each use 
sophisficafed, convolufed fixing functions fo achieve hypofhesis-free read-over-wrife fheorems. 

Fixing convenfions are often unnecessary in fyped logics. In such a logic, when we define funcfions 
such as PLUS : Nat x Nat —)■ Nat, fhere is no need fo include any fype hypofheses in fheorems such as 
the commutativity of PLUS, because any attempt to call or reason about PLUS on non-NAT arguments is 
simply an error. On the other hand, even in such a logic, fixing convenfions may be useful for modeling 
behavior of operations whose intended domains are nol easy fo describe using types. Lamport and 
Paulson [15] provide an engaging discussion of fhese sorts of issues. 

5.2 Data Struture Libraries 

There has been significanl previous work fo develop dafa sfrucfure libraries for ACL2. An early example 
is Brock’s classic data-structures library, which fealured macros such as def structure [3]. As a 
concrete example of using fhis macro, we mighf wrife: 

(defstructure student 

(name (:assert (stringp name) :type-prescription)) 

(age (:assert (natp age) :type-prescription))) 

This produces a consfrucfor fhaf simply conses fogefher ifs argumenfs and accessors fhaf simply car/cdr 
info fheir argumenf. No fixing is done, so fhe consfrucfor only produces a well-formed student-p if ifs 
argumenfs have fhe proper fypes, and fhe accessors may produce ill-fyped resulfs when applied fo non- 
student-p objecfs. Accordingly, reasoning abouf such sfrucfures typically requires fype hypofheses. 
The more recenf def aggregate macro follows fhis same approach. 

ACL2’s single fhreaded objecfs [2] are in many ways similar fo def structure and def aggregate. 
Alfhough if probably would make liffle sense fo define a sfudenf strucfure as a sfobj, we can do so: 

(defstobj student 

(name :type string :initially "") 

(age :type (integer 0 *) :initially 0)) 

'Correspondence with Bob Boyer and J Moore. 
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The resulting recognizer, accessors, and mutators are similar to those produced by def structure or 
def aggregate and so reasoning about these operations usually requires type hypotheses. On the other 
hand, the recent addition of abstract stobjs QO] makes it possible to develop alternative logical interfaces, 
e.g., we could arrange so that the student stobj was logically viewed as an FTY product object. 

The def data [4] library by Chamarthi, Dillinger, and Manolios features an alternative macro, also 
called defdata, that supports introducing richer types, such as sum types, mutually recursive types, 
etc. This framework also features integrated support for counterexample generation, an exciting feature 
which FTY does not yet have. To define a similar student structure with defdata we might write: 

(defdata student (record (name . string) 

(age . nat))) 

This similarly results in a studentp recognizer, constructor, and accessors like student-age. Un¬ 
like def structure or def aggregate, the underlying representation of these functions is based on an 
optimized variant [12] of Kaufmann and Sumners’ records book [14], and the macro provides special in¬ 
tegration with ACL2’s Tau reasoning procedure. However, the general approach to type reasoning about 
these structures is unchanged: we still require type hypotheses to establish that the construct produces a 
valid studentp, that student-name returns a string, and so forth. 

Despite type hypotheses, macros like def structure, def aggregate, and defdata are certainly 
very useful. Def structure has long been used in ACL2 developments, including recent work such as 
the modeling by Hardin, et al. [13] of the LLVM compiler project’s intermediate form in ACL2, and 
the formalization by van Gastel and Schmaltz [9] of the xMAS language for communication networks 
on multi-core processors and systems-on-chip. For many years, we used defaggregate and other 
std/util macros at Centaur as the basis for our VL library, microcode model [7], and other internal 
applications. In our experience, porting these libraries to FTY was not difficult and has helped to simplify 
our code. 

5.3 Make-Event Metaprogramming 

In 2004, Vernon Austel developed [JJ an experimental variant of ACL2 that added support for a certain 
type system. He explained that this work had required modifying ACL2 because “a usable type system 
must constantly extend the set of functions whose type it knows about; this seems to require storing type 
information in the ACL2 world, which macros currently cannot do,” and proposed extending ACL2 with 
something like make-event to “allow others to experiment with type systems without having to hack the 
system code.” Indeed, our FTY library makes extensive use of make-event to record the associations 
between type recognizers, fixing funcfions, and equivalence relafions, and to look up (via define) the 
type signatures for functions. 

6 Conclusion 

FTY is a new data structure library for ACL2 that provides deep support for using fixing funcfions 
to avoid type hypotheses in theorems. Its successful use may require somewhat more discipline than 
similar libraries such as std/util or defdata. In exchange, it provides a strongly typed programming 
environment that can help to catch errors during development while largely avoiding type hypotheses 
during theorem proving. 

Having a good data structure library is tremendously useful when developing large systems in ACL2. 
A fixing discipline is one part of this, but FTY is also increasingly mature and capable in other ways. 
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e.g., it retains much of the std/util look and feel, with features such as XDDC integration, convenient 
b* binders, readable make/change macros, etc. We are now using FTY as for large ACL2 libraries such 
as SV and VL libraries, and have been pleased with the results. 

The source code for FTY is included in the ACL2 Community Books under the centaur/fty di¬ 
rectory. Beyond this paper, the FTY library has extensive documentation, which includes more detailed 
information on the available options for each macro. The centaur/fty directory also includes various 
test cases that may serve as useful examples of using the library. 

We hope you find FTY useful. 
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